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therefor /J/'* . ' / . iSi V"; ' 7:,r i? • 

(57) A control system built 'around plural 
.objects is provided with greater fiexbilit^ and 'easy cus- 
tomizability, and ^ programming method for said control 
system is provided. . • 

An interlace object (15) capable of two-way communica- 
tions is created and lised when first OCX (10), >a com- 
mon object, creates and controls second OCX (11). 
This interface object (15) is able to return evehts gener- . 
ated by second OCX (11) to first OCX (10), and first 
OCX (10) is able to completely control the operation of 
second OCX (11). 
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Description 

The present invention relates to a control system comprising plural common objects that can be shared by plural 
application programs, and relates specifically to a control system that can be customized using said common objects, 

5 to a programming method for said control system, and to a peripheral devices control system applying said control sys- 
tem and programming method. 

Computers are used today to execute a wide range of processes and use a variety of peripheral equipment that 
can be connected to computers. It is therefore necessary to build and provide flexible computerized systems that can 
be customized to the user's working environment and needs. For example, it is possible today to connect different types 

10 of printers, displays, bar code readers, and other input/output devices using a common standard bus. When the soft- 
ware needed to control these I/O devices is installed in the computer, the control system must be able to appropriately 
control each of these many devices. It is also easy to build a networked computing environment in which plural comput- 
ers are connected to a common network. This makes it desirable to be able to control the processes and procedures 
executed by each computer on the network . .. \ H 

is One method of constructing this type of flexible system executed in a computer is to create plural common objects 
that can be shared, and have the operating system and application programs use these common objects. An example 
of such a method is the Object Unking and Embedding (OLE) technology developed By Microsoft Corporation, and the 
related OLE Automation or OLE custom controls (OCX) which are interfaces for OLE programming. 

One problem with such programming methods, however, is that when one common object uses another common 

20 object, the functions of both common objects cannot be fully utilized. Using the custom controls OCX described above, 
for example, the client OCX can access properties and methods from the server OCX. but the client OCX cannot 
receive events generated by the server OCX. ' / 

This means that if the first or client OCX is an object for controlling the functions of a peripheral device such as a 
printer, and the second or server OCX is a : driver for the type of peripheral device controlled by the first OCX, the first 

25 OCX can control the functions, of the peripheral device via the second OCX but it cannot receive peripheral device sta- 
tus information through the second OCX. 

The object of the present invention is therefore to resolve this problem by providing a method and system for easily 
constructing a variety of operating systems and application programs using plural common objects that can be shared 
by plural application programs. More specifically, the object of the present invention is to provide a method and system 

30 that improve the interface between common objects and to enable ^ach common object to fully utilize the functions of 
other common objects. , . , 

For example, when one common object is the client or. controller and another common object is the server, events 
generated by the server object can be recognized by the client or controller object, and to provide a method for con- 
structing such systems. 7 

35 The present invention specifically applies to a system cornprisjng plural control objects used as common objects, 
each comprising a first function for accessing prppertl^ incrudihg ^ values and for invoking methods to call 
implemented functions and a second function for posting events i he) udi rig asynchronously occurring actions. 

When a control system executable by a computer is constructed by means of this system, at least one second con- 
trol object is created by a first control object with the first, co^ second object. In this type of cbn- 

40 trol system, the present, invention provides Jsul interface obj^^havin^ai funcdoh fbr^cbm^ properties or 

methods between the first control object and the second pk?j ecf, and a f uhttfonftir communicating events from the sec- 
ond control object to the first control object. 

It is possible by means of the present invention for a first control object and a second common object to communi- 
cate all properties, methods, and events therebetween by means of a two-way communications interface object. It is 

45 therefore simple to construct a control system capable of fully utilizing functions made available as control objects. 

In a control system of the present invention according to a first erribodi merit, the first Control object can receive 
events generated by a second control object, execute processes appropriate to the received event, and rapidly commu- 
nicate said, event to another control object, application program, or operating system using said first control' object. The 
present invention is therefore able to build a control system that fully utilizes the functions of all common objects. 

so A control system according to an alternative embodiment of the present invention provides a second interface for 
receiving events to a control object comprising the .functionality of a common object. The control object comprises a 
function for informing an application program or other Control object of specific properties, including attribute values, or 
methods for calling implemented functions, and comprises a first interface for posting events including asynchronous 
actions. • , . ... ... 

55 In a control system according. to the alternative embodiment of the present invention, a first control object com- 
prises a second interface for receiving events. Events occurring asynchronously in a second control object can be 
immediately communicated through the first interface .and second interface to the first control object, or to higher level 
application programs. It is therefore possible to easily construct a variety of control systems by means of a first control 
object creating a second control object, and appropriately controlling the first control object and the second control 
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object, thereby achieving a high speed, multiple function control system. 

The present invention will become more fully understood from the detailed description of preferred embodiments 
given below and the accompanying diagrams wherein: 

5 Fig. 1 is- a block diagram of the basic configuration of a control system according to the first embodiment of the 
present invention. 

Fig. 2 . is a flow chart showing the process for confirming a connection between an interface object and a control 
object in the control system shown in Figi. '1 and 7. 

io . • - • 

Fig. 3 . is a f low ctjart showing the .process for establishing a connection and event correspondence between an 
interface object and a control object in the control system shown' in Figs. 1 and 7. 

Fig. 4 is a flow chart showing trie process whereby a control object notifies the interface object of an event in the 
75 ,i .control system shown in Figs. 1 { and.7. . r 

Fig. 5 • is a block diagram ^fja control's^ the first embodiment of the present invention. 

Fig. 6 is a block diagram of the system for control ling' the peripheral deyices'of a point-of-sale (POS) system con- 
20 structed with a control system using the first embodiment of the present invention. 

Fig. 7 is a block diagram of the basic configuration of a control system according to the second embodiment of the 
present invention. ^ ^ . 

25 Fig. 8 is a block diagrarn ofjhe system "fpr controlling Jhe peripheral devices of a point-of-sale (POS) system con- 
structed with a control system using the second embodiment of thef present invention. 

Embodiment 1 . t . x .. |f;i> . . a 0: ,. f 

30 The first embodiment of the invention is described in detail below based on ah implementation for the Microsoft 
Foundation Class (MFC), an applications development environment published by Microsoft. * 

MFC provides various libraries used to facilitate OLE programming, and makes it possible to develop systems using 
OLE Automation functions written in object-oriented jxogrammir^ languages such as Microsoft's Visual C++. As shown 
in Fig! 1 , these systems are constructed with hierarchical links between the application program (container application) 

35 20 and commonobjects OCX 10 and 1 1 written to enable shared use throughout the system. 

These.common objects OCX 10 and 1.1 can be provided as components of executable software (EXE) modules; or 
as Dynamic Link Library (DLL) modules. Executable software and'DLL modules providing these common object serv- 
ices are known as EXE servers-or DLL servers; the oprrtaner appfication 20 is known as a client or controller. Common 
objects used in the OLE architecture may be'de^ class provided in the MFC library, for exam- 

40 pie. The CCmd Jarget class supports the lUnknown jnt^rtac^ objects and the interfaces needed 

as common objects. The CCmdTarget class also supi^ which delivers structures such as 

data storage structures fromfrie controller, and which can ['access commort object properties and methods by calling 
the member function Invoke. . . y . . 

Note that properties are^ attributes of, the t common obj^/ Proj^rties;^ ah object associated with a printer, for 

45 example, may include ink colors. toi.niiir^ operation execute^ when a given push-button or key is 

pressed. Methods are functions,, such as. editing ^ functions; Incremented in the <x>rhrnbn object and are called to access 
and use functions of the common object. s . . . 

In addition to providing access to properties and methods for client objects, iximmbh objects also announce events. 
Events are asynchronous external actions, such as clicking; a mbuse button or pressing a key, accessing the common 

so object. A common object normally announces an event by falling 'the Invoke function of the controller in a manner sim- 
ilar to the way in which the controller accesses properties and invokes methods. If the connection point for the event 
does not have a valid interface, the event will be ignored. .Referring to Fig'.' 1, IConnectibnPoint 12 is the interface that 
provides a connection for announcing events. 

Container application 20 in Fig. 1 is a control system using a common object. Iri the control system shown in this 

55 figure, container application 20 creates a first object OCX 1 0. and this first OCX 1 0 creat s a second object OCX 1 1 for 
control. A COIeDispatchD river class is included, jri the MFC library tp handle the complexities of calling the Invoke func- 
tion from a container application or OCX. By bailing member fdncrions of objects derived from this class/first OCX 10 
can create the second OCX .1 X which is another' control object, aind can then use the properties and methods of the 
second OCX 11. 
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When common objects in the server are used, it is possible, for example, that a given common object may reside 
on a processor different from the processor on which the container application is executing. In such cases, the control 
system of the present embodiment can be constructed by executing a communications process on each processor 
where the controller and the server reside. It is also possible to copy the common objects used on one processor to 
5 build a control system. In either case, however, it is not possible to modify the code of common objects in any way, and 
memory is reserved each time the common object is activated. The coritrol system communicates between the server- 
side common objects and the controller using the reserved memory. 

It is therefore possible for the controller to use the same common object multiple times, in which casfc the common 
object need not be copied multiple times, but the data, stack, and other requisite memory areas are reserved for each 
10 use. In this specification, each distinct use of a common object, regardless how it is implemented, is referred to as an 
object. 

When the first OCX 1 0 is the controller and it calls a second OCX 1 1 , it can rise an interface object derived' from 
the COIeDispatchDriver class as described above. Note that the term "interface object" refers to distinct uses of Inter- 
face objects, regardless how they are created, similar to that described above for common objects. The Visual C++ 2.0 

is COIeDispatchDriver class supports a function for passing methods and properties to the second OCX through the IDis- 
patch interface, but it does not support a function for capturing events returned by the second OCX. This does not cre- 
ate a problem when the container application 20 recognizes the Second OCX 11 used by the first' OCX 10 and 
comprises a function for capturing events of the second OCX 11. When the container application 20 does not recognize 
the second OCX 1 1 used by the first OCX 10, however, it is not possible to capture the events generated by the second 

20 OCX 11. 

When a common object is already identified, or a common object is prepared for a specific container application, it 
is possible either to construct the control system such that a, common object can pass events to the container applica- 
tion, or to control processing such that the second OCX 1 1 does not generate events affecting the container application. 
It is desirable, however, to have the ability to construct a more flexible control system to support different external . 
25 input/output devices and adapt to a wide range of computing environments. It is therefore necessary to support an envi- 
ronment in which one common object can be customized using another common object, e.g., an environment in which 
the container application 20 can berCustomized using common objects. - « . 1 >: 

Referring again to Fig. 1 , the present invention provides an interface object 15 enabling two-way communications 
between one common object and another common object, thereby enabling the construction of more flexible control 
30 systems. If common objects are linked using an interface object enabling two-way communications, there is no need for 
container application 20 to recognize the second OCX 1 1 , and the second OCX 1 1 can be provided as an object unaf- 
fected by the container application 20. 

To achieve an interface object providing complete support even for events, the present embodiment provides a 
COcxDispatchDriver class handling dispatch processing fQr one OCX to use another OCX. This; COcxDispatchDriver 
35 class is an object class derived with multiple inheritanqeffrom the QCmdTargetclass and the COIeDispatchDriver class, 
and may be represented by a C++ statement as follows: 

class COcxDispatchDriver: public CCmdTarget, public COIeDispatchDriver {...}; . , 
Various classes and declarations in the examples shown herein conform to definitions provided in the MFC library 
mentioned above and in a Windows Software^ evelqpers Kit (SDK) provided by Micrpsoft, Other implementations are 
40 possible. ■ . ■ .. ■ ;• r.- . • -■ • "J- : ., . > 

As described above. the CCmdTarget class is the class for deriving- objects witlra server function and it supports 
the IDispatch interface. It is therefore possible to achieve an interface object that operates as a server to second OCX 
11 while supporting an interface through which events can be passed. .-.,..», . \ 

The COIeDispatchDriver class is an object class that operates as either client or controller for the second OCX 11 
45 and it comprises a function for easily accessing methods and properties. ; cl «. 

The COcxDispatchDriver classis an object class comprising the two main functions described above while inherit- 
ing and supporting all of the functions of both parent classes. The COcxDispatchDriver class is appropriate as an object 
class generating an interface object according to the present invention. Because there is no overlap between the oper- 
ation and function of the CCmdTarget class and the COIeDispatchDriver class, there is also no problem created by mul- 
so tiple inheritance. 

The specification for the derived COcxDispatchDriver class is as follows: 
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Class COcxDispatchDriver: public CCmdTarget, public COIeDispatchDriver { 

COcxDispatchDriver::COcxDispatchDriver(); // create 
5 public: // member data ' 

UlNT'm ObjlD; //object ID initialized uniquely by EstablishConnectionO 

IID mJIDEvents; // event interface ID 

UlNT\m_n Events; . , // number of events 
10 CDWoVdArray mdispID // array for converting dispatch ID using user-defined- dispatch 

map ' * • *" ■ *' : .■ .. 

public:. t . //.member functions . 

BOOL EstablishConnection(REFCLSlD clsid, COIeException *pErron = NULL); 
is ^ '"' 7/ creates an object, and enables an access connection to methods, 

'. . . f ,l properties, arid events ' 1 

void DestroyConnectiontb //.releases the. connection, and deletes the object. 

} ■ . — . . .. • • i * ■ - ■ r . - • 



To achieve a general-purpose class/the COcxDispatchDriver class does not include ah event processing function . 
(event handler) - It is therefore necessary ta describe an event handler for specific OCX events in any objects derived 

25 from COcxDispatchDriver. This is accomplished as follows. ' -* 

A dispatch map is first described according lo the external* name of the everrt(s) returned by the OCX. ifihe 
sequence of events in the dispatch' map may be freely ordened; i and the correlation to the sequence of events actually - 
received is established when the event connection is established: Note that it is necessary to fully describe all OCX 
events. * . • ■ • ; >*- •._•■„.. 

30 Dispatch map entries may be described 'using a macro call* such as follows with the major parameters beings in . ^ 
sequence, the dispatch driver class name, external event name, event handler name, return values, and parameter v 
data: • 1 • ■ . : . 

DISP_FUNCTIONLDSoprn, "Control Complete Event", ControlCompleteEverrt; VT_EMPTY, VTS_14 
VTS_SCODE vTSJ>BSTR VTS_I4) ; : : - r . 

35 By describing the dispatch map according to the external event name, - events created by the OCX can be received -. * 
in an intuitive; easily understood format: Program*<levelbprr1eht cahbe greatly facilitated by declaring the event handler 
using a normal function prototype statement as follows: 

void ^DSoprn-ControlCompleteEventClong ControtiD, SCODE Result, BSTR FAR*, pString, longdata);. *"* : ^ 
The process for setting the connection between second ©GX TV and interface object 15 providing an interface a* 

40 derived fromthe COcxDispatchDriver dass Is described be^ow wfth 5 reference to the flow charts in Fig. 2 and Fig. 3. By . 
simply calling the member function COcxDispatchDriver::EstablishConnectionO, the interface object 15 of the present 
embodiment creates an object (second OCX), supplies tfie^meihods <and properties/ and establishes a connection for 
receiving events. - « -• ^ - *v> ~ y • , t 

When EstablishConnectionO is called, the second 0CXM?1 defined by clsid (the 'variable storing a 128-bit value 

45 identifying the OCX) is created and-begins executing as shown instep 31 of Fig, 2. When the operation of second OCX 
1 1 is confirmed in step 32 ; the IDispatch interface of this OCX-I T isidbtained and stored in step 33. The interface object 
15 can call the Invoke function and serve methods and properties to the OCX1 1y through the IDispatch interface. If the 
establishment of a connection for passing properties and events' to : the second OCX 11 is* confirmed in step 34, the 
event interface of the second OCX 1 1 is checked in step 35/ 

so If an evenf interface is confirmed in step 36. the event-related tlata is stored in step 37. The event name list pre- •.• 

pared in second OCX 1 1 is stored to EntryNames, the dispatch ID list is stored to DisplDs. and the parameter data list • 
is stored to Paramlnfo. If these processes are confirmed to have executed and completed normally in step 38 ; the proc- 
ess defining the correlation between the dispatch map and events is executed according to the flow chart shown in Fig. 
3. If, however, a connection cannot be established, an error processing task displaying an error message, for example. 

55 is executed in step 39. 

The process defining the correlation between the dispatch map and events is described next using the flow chart 
shown in Fig. 3. 

This process starts by clearing the counter fcnt to zero in step 41 . The counter fcnt is then read in step 42. Step 43 
checks whether the event name EntryNames(fcrtt) obtained from second OCX 1 1 is in the dispatch map pDispMap pre- 
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viously defined in the event handler of interface object 15. If the event name EntryNahies(fcnt) is in the dispatch map 
pDispMap, it is then confirmed in step 44 whether the parameter data Paramlnfo(fcnt) matches the dispatch map pDis- 
pMap previously defined in the event handler. 

If step 44 returns YES, step 45 then defines array m_displD is defined for converting the dispatch ID DisplDs(fcht) 
5 of the event obtained from second OCX 11 to an index in the dispatch map pDispMap previously defined in the event 
handler. The counter fcnt is then incremented in step 46, and the loop from step 42 to step 46 is repeated for each 
remaining event. 

When the correlation to the dispatch map pDispMap is established,, £tep 47 sets a connection for events from sec- 
ond OCX 11. In this step the event connection is set by passing the address of the IDispatch reserved in interface object 
io 15 for receiving events to I Connection Point, which is the interface for object-to-pbject &hnecti(Dns. This makes it possi- 
ble to pass events to interface object 15 by calling the Invoke function of the second OCX 11. More specifically, it is pos- * 
sible for interface object 15 to receive events passed from second OCX i 1 . 

Step 48 checks whether the connection is successfully established, the array mjdispID for converting the event dis- 
patch ID is stored in step 49. . . 

75 If the preceding steps are all completed normally and the connection between interface object 15 and secbnd OCX 

1 1 is set, it is possible from step 50 to pass the methods and properties of second OCX 1 1 to first 66x 1 0, and to pass 
events from second OCX 1 1 to first OCX 10, In practice interface object 15 must notify first OCX 10 that an event has 
been received from second OCX 1 1 . A public member function that is balled when interface object 15 receives an event 
is therefore provided in first OCX 10, and interface object 15 calls this member function accordingly. 

20 It is therefore, possible by using interface object 15 of the present embodiment for two-way communications 

between common objects to be maintained. This makes it possible to construct a more flexible control system using 
common objects. 

Note that the interface object of the present embodiment as just described establishes a cross-reference between 
the event array of the common object and the event array of the interface object, thereby establishing a correlation 

25 between the arrays when establishing the event connection. This correlation i makes it possible to set a connection if the 
types and numbers of events match even if first OCX 10 is hot fully informed about the second OCX 11 interface. In 
other words, two-way connections between plural common object can ^ established if the properties, methods, and 
event names match. Developing common objects is therefore easier, and flexible Systerhs offering greater security and 
reliability can be constructed even when updated components and different objects are used. 

30 Interface object development is also significantly easier and requires less time because the event handler that is 
activated when an event is received can be described using normal function syntax. 

Fig. 4 is a flow chart of the process executed when lnvoke(EventlD t ...) is called from second OCX 1 1 to post events 
of the IDispatch interface of interface object 15. The IDispatch interface provides ihvokeO and the basic functions sup : 
porting InvokeO (including AddRefO, ReleaseO,, and ,Queryinterface(IID&, LP UNKNOWN*)), and responds through 

35 Querylnterface() to the interface ID (I ID) of the event generated by the other OCX. 

When InvokeO is called, the structure storing the event .parameters and the dispatch ID defining the current event 
type are passed to interface object 15. Interface object 15 then. checks iri step 60 whether the parameters are valid. If 
the parameters are valid, step 6i converts the displDMember array of events obtained from second OCX 1 1 according 
to the prepared event handler dispatch map pDispMap based fori the^nversiori array m_displD. The event handler cor- 

40 responding to displDMember is then exacted from pDispl^^ln step 62. Step 63 confirms whether the event handler 
is valid or not.lf the event handler is yali&the event handler .cprr^r^hdihg tp the event is call#d in step 64 and the proc- 
ess defined by the event handler, e.g., a process informing first OCX 10 of the event, is executed! 

A variation of the first embodiment is shown in Fig. 5. in this variant control system, first OCX 1 0 generates plural 
objects 11a and 1.1b of the second OCX with first OCX 10 controlling both second OCX objects liaand ilb. Morespe- 

45 cif ically, first OCX 1 6 is the client or controller for the two second OCX objects 1 1 a and l ib. In this control system the 
interface between first OCX 10 and second OCX objects 1 1a and ilb is provided, by means of the interface objects 15a 
and 1 5b that created the two ± object objects 1 l a and. 11 b ? ( „ , 

Each time an interface object derived from the COcxDispatchDriver class is generated, a unique ID is generated 
identifying each interface objetf ." When an event is relayed from the interface object to first OCX 10, the first OCX 10. is 

so able to reference the ID upique.to each interface object. This ID is a unique value assigned when the interface object is 
created, but may as necessary be changed to an appropriate value by the interface object creator, i.e., by the first OCX 
in the present embodiment ....... 

When plural objects 11a and i 1b of the second OCX are created as shown in Fig. 5, events generated separately 
by second OCX objects 11a and 11b are transmitted to the first OCX via interface objects 15a and 15b. The first OCX 

55 can therefore clearly determine which of the two second QCX objects generated the events by referencing the unique 
ID assigned to each interface object, It is therefore possible as described abqve us;ing the interface object of the present 
embodiment for a common object (fi'rsjt OCX) to spawn and use multiple second objects (second OCX). Even in this 
case, the creator (first OCX) of the pluralobjects can identify which second OCX object generated an event without indi- 
vidually managing the plural objects. 
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The event handlers are not contained in the first OCX object that spawned the plural second OCX objects, but 
rather are contained in each of the interface objects, this makes it possible for the creator (first OCX in this embodi- 
ment) to reliably determine what events were generated with what parameters by which one of the second OCX objects. 
It is therefore sufficient for the second OCX objects to simply post the respectively generated events to the corre- 
s sponding interface objects, and rt is not necessary for each object to determine whether that object is the first object or 
whether other objects of the same class exist . [ 

By using an interface object according to the present invention, a control system comprising plural common objects 
can be flexibly and easily constructed, rt is only, necessary to provide each common object with minimal information 
aboufthe other common objects it will use, and each common object needs only minimal information about the other 
w common objects used.,lt follows tret even greater encapsulation of individual common objects is possible. At the same 
time, the interface object according to the present invention comprises a two-way communications function capable of * 
communicating events! and can thereby" fully manipulate other common objects while obtaining full benefit of the func- 
tions provided by the other common objects. 

Although a two-layer control system comprising first and second custom controls OCX has been described in the 
75 preceding embodiments of the invention, control systems with a deeper hierarchical structure of three or more layers 

can also be constructed ip ths s^rpe rnanr\er v 

It is also possible to pcfiieye an interface between an application program and a first custom controi OCX using the 
interface object described above. It will also be obvious that such control systems shall not be .limited to application pro-' 
grams and may include operating systems. 
20 Furthermore, whilejthe preceding embodiments have been described as achieving the object interface of the 
present invention under the MFC environment supplied by Microsoft, an object interface comprising the same function- 
ality can be created without using the MFC library. Moreover, systems using common objects substantially equivalent 
to those described above can be constructed under any system environment using shared common objects; therefore, 
the invention is not limited to implementation^ developed by Microsoft OLE Automation or any other specific develope- 
rs menttools. s ". . .. 

Systems using common objects as described can be achieved on stand-alone computers using a single processor, 
on a system comprising multiple processors, or pn multiple systems connected in a network environment. 

By using the interface object described,' the* present embodiment provides a control system offering great extensi- 
bility and easy program development it wfll be obvious, however,' that a common object comprising both the described 
30 interface object and the functions of the first* custom control OCX can be achieved, and a control system enabling two- 
way communication of properties, methods,, and events can be constructed with a system using this OCX. 

Application in a peripheral device control system 

35 An example of a peripheral device control system comprising an interface bbject according to the f ifst embodiment 
above and plural common objects is shown in Fig. 6. The specif ic ^control system shown in Fig, 6 is a 'point-of : sale 
(POS) system built around a personafcorrputer (PC) 70. The PbS application program 71 is installed in PC 70 and 
operates under operating" system (OS)' 10^. 6$ 105 : has a furWbori rfor controlling the peripheral devices normally 
required by a personal computer using k keyboard BHvef 106, display^ monitor driver 107, and other device drivers. Data 

40 transfers between POS application program 71 , mV.)<eyt)oard f ^briifpr, and other devices are controlled by OS 105. 

In addition to these peripherW devices .nofmklly provided With any personal computer, a POS system also typically 
comprises a customer display iVb for displaying the purchase amount hnd bthei' information for customer confirmation; 
a receipt printer 1 1 2 for printing purchase receipts, for example; a slip printer 1 13 for imprinting checks and other slips; 
and a cash drawer! 15 for ridding mbhey. These' peripheral! devices are Connected to an RS-232C port or other 

45 input/output port. For example, customer display 110 is connected to the RS-232C port and printer 1 1 1 comprising both * 
receipt printer 112 and slip printer 113 is connected through tfie customer' display' 1 10. Cash drawer 115 is placed 
below printer 111 and is operated through the control circuitry of printer 1 11. 

Numerous manufacturers market a variety of such peripheral devices, enablinjg the. user to select the devices best 
suited to the user's POS.systerq su-chrtecture and application.* Because the specifications of different peripheral device 

so makers and mcxtels differ widely! however, it is extremely difficult tcr construct an application program suited to ail avail- 
able peripheral devices. Specifications may also change as peripheral devices are upgraded. It is therefore convention- 
ally difficult for users to construct POS systems using peripheral devices selected at the convenience of the user: When 
individual peripheral devices are upgraded, the new version of a currently-used peripheral device is also not necessarily 
immediately adaptable to existing POS systems. 

55 When the control system is constructed using the custom controls OCX and interface object of the present inven- 
tion as described above, an extremely open system can be constructed. It is therefore possible to simply construct a 
POS system using various different rfi^efsorperiph also simple to accommodate updated versions 

of the. peripheral devices. For examplefpeWph6ral device control sj'Stern 72 of the presenfembodiment shown in Fig. 6 
comprises three levels of custofn controls OCX: The first OCX level has the receipt printer format conversion OCX 73 
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and a slip printer format conversion OCX 74. 

OCX 73 and 74 execute the process arranging the data sent from the POS application program 71 , e.g., the list of 
items sold and the total price, to a specific printing format. The specific printing format may be defined by OCX 73 or 
74, or the formatting properties may be defined by lower-level custom controls OCX, i.e., receipt printer control OCX 75 
or slip printer control OCX 76 in this example, with conversion OCX 73 or .74' doing the actual formatting using the prop- 
erties of these custom controls OCX. In either case, POS application program 71 only needs to pass the output data to 
conversion OCX 73 or 74 irrespective of the print out format. The interface format can therefore be limited to provide an 
application program with high general utility. . 

It is also possible to convert data output from the application program in a specific format by a first level OCX to a 
format common to the lower OCX. This makes it possible to increase the general utility . of application programs sepa- 
rately developed using the custom control objects OCX. ... 

Level 2 custom controls OCX include receipt printer control OCX 75, slip printer control OCX 76, cash drawer con- 
trol OCX 77, and customer display. control OCX 78. These custom control objects OCX 75 : 78 provide a predetermined 
application programming interface (API) to the application program and other high-level OCX. The application program 
and high-level OCX can therefore simply supply data according to a predetermined APi specification irrespective of the 
manufacturers and models of the printers and other peripheral devices that are' part of the POS system. The custom 
controls OCX 75 - 78 on this level convert data input according to a common API specification to the data format of the 
lower-level OCX, i.e., to the specifications of the peripheral devices composing the actual system, using the properties 
of the low driver-level OCX reflecting the specifications of the individual peripheral devices. _ 

Level 3 custom ^controls OCX include printer driver OCX 91 and 92, cash drawer driver OCX 93', and display driver 
OCX 94. These.- custom, controls OCX 91 - 94 are common objects supplied With and corresponding to each of the 
peripheral devices, each common object normally differing according to the manufacturer or model of the peripheral 
device. These driver-level OCX 91 - 94 describe, for example, the maximum number of printing lines, the line pitch/and 
other printer-specific characteristics and settings (i.e., the printer status) as device properties. These properties can 
then be referenced by higher-level objects or the application program. The driver-level objects also define methods for 
outputting print commands, including commands to print the text string at a specif ic position. These driver-level custom 
controls OCX output commands specific to the corresponding peripheral device through the appropriate port driver. The 
printer OCX, for example, outputs the line feed distance (i,a. line pitch), line feed commands, print data and print com- 
mands, and automatic paper cutter commands in a predetermined sequence to the printer through port driver 100 
based on the specif ied print position and printing string. 

Level 3 OCX also receive asynchronously occurring events (actions) back from the corresponding peripheral 
device. The printer driver, for example, receives the process result and error status. sent from the printer. The contents 
of these actions are then interpreted based on the specifications of the corresponding peripheral device, converted to 
a universal format, and returned to the higher-level OCX as an event. 

High and low level OCX are linked by means of interface objects 81a, 81b, 82a - 82d, each of which is capable of 
two-way communications, in the control system of the present embodirnent. In addition to methods and properties, 
events can also be communicated. Level 2 control OCX 75 - 78 receive these .events and pass the events, either directly 
or after conversion to a universal format, through interface objects 82 a - 82d to a higher level OCX or.applicatioh pro- 
gram. Based on the received event, the application program or high jeyel QQX can then output a feedback message to 
the user, initiate an error processing routine, or execute another.d^ined.^rpcej^. It is therefore possible in the control, 
system according to the present embodiment to quickly execute the process appropriate to asynchronously, occurring 

events. . ; . - . ■••■.,.* : v . c- - , lti . . 

By using custom controls OCX, the control system of the present emb^imerrtjs' a system that can be. easily cus- 
tomized to match the peripheral devices selected by the user. It js also a control system that can execute the appropri : 
ate processes with high speed because two-way communication of properties, rhetho^Vand events between custom 
controls OCX is assured. . r. . , : , , 

The control system of this embodiment is described, in further detail using a receipt printing function, by way of 
example only. . .. • -■, 

One property of printer driver OCX 91 , which is a level 3 OCX, is the status of receipt printer 112 (printer status).. 
One method of printer driver OCX 91 outputs print commands to receipt printer 1 1 2. Printer driver OCX 91 also asyn- 
chronously generates events corresponding to real-time error status information supplied by receipt printer 112. This 
error status information includes np-paper or paper run-out and cover open status information. 

Data from POS application program 71 is passed to receipt printer format conversion OCX 73, a level 1 object, and 
is converted thereby to the predetermined format before being passed to leyel 2 receipt printer control OCX 75. When 
receipt printer control OCX 75 calls the print execution method of printer, driver OCX 91 , printer driver OCX 91 sends 
the appropriate data and commands to receipt printer i 1 2 and thereby .prints a receipt. The receipt printer 1 1 2 executes 
the commands received from printer driver OCX 91 and returns printer status to. printer driver OCX 91 . 

The printer driver OCX 91 interprets the returned status and terminates printing without generating an event if no 
error is indicated. It is also possible for the higher level receipt printer control OCX 75 to determine the result of the 
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printer process by referencing the printer status property. Communications for this referencing are handled by interface 
object 82a. 

If an error during print command execution or while in the standby state, receipt printer 1 12 sends the error status 
to printer driver OCX 91* Printer driver OCX 91 generates an event in this case and notifies the higher level receipt 

5 printer control OCX 75 that an error has occurred through interface object 82a. Receipt printer control OCX 75 can exe- 
cute specific processes for a given event and notify the format conversion OCX 73 and POS application program 71 
through interface,object 81a/ 

In addition to these properties, methods and events, other properties and events unique to slip printing are prefer- 
ably provided in the driver OCX 92 for.slip printer 113. For example, by adding a slip paper presence property to the 

10 driver OCX 92, higher levei custom controls OCX and applications can regulate the timing at which the print command 
is issued. By adding paper insertion detection and paper end detection events to the event list, the application program 
can be controlled to smoothly execute the normal post-printing processes and error processing. 

The cash drawer control OCX 77 communicates with cash drawer driver OCX 93. The cash drawer driver OCX 93 ' 
comprises a .cash drawer open method, and a ca£h drawer status property that can ; be read to determine whether the 

is cash drawer is open of closed. Events, are issued when cash drawer errors occur and an open cash drawer is detected. 
The customer display cbjTtrol OCX 78 cornrnunicatfes with 5 display driver OCX 94, the methods of which include dis- 
play commands specifying the display portion and the display text string. Properties include the number of display col- 
umns, the display color, and other display specifications. Customer display control OCX 78 applies the display data 
according to these properties. Note that because the customer display is a dumb display, errors and similar events are 7 

20 rare. It is therefore possible to eliririinate the event posting function from cfisplay driver OCX 94. 

As described above, it is possible using the interface object according to the present invention to easily construct a 
control system comprising a multiple level hierarchical structure using plural custom controls OCX, and to respond rap- 
idly to asynchronously occurring actions including errorsV Note also that the control system of the present embodiment 
is an open control system that c?in be easily adapted to a variety of peripheral devices connected to a personal compu : 

25 ter. J r ;•'■'*' ■ " : •* 

It is necessary to 'replace only the common driver object controlling the slip printer function with a new driver object 
corresponding to the new specif ications when the slip printer in printer 1 1 1 is'replaced with a slip printer having different 
printer function specifications (e.g., a cfiffereht number of print columns or a different executable command set). Once 
the slip driver object has been updated, the peripheral device control system creates a custom control OCX from -the 

30 common object for the new driver arid automatically generates a control system suited to the new printer. This same 
principle applies when driver specifications change as a result of updating the printer driver, i.e., it is necessary to 
replace only the. common object corresponding to the' updated driver object, and it is not necessary to modify any other 
common objects or application program. j " 

This is also true for the customer display and other' peripherardevices, i.e., when the specifications change, the 

35 control, system can be automatically modified by updatirtg the common driver objects. When a POS system is^con- " 
structed with bar code readers arid other additional peripheral devices, the appropriate low-level custom coritrols^.OCX 
are created by the application prograrfi or high-l<evel OCX rf the Common objects for controlling and driving these addi- 
tional peripherai devices are provided somewhere in thepersohal computer system. As a result, a peripheral devices 
control system capable of drivinb the bar code reader and '6Wer jSferiphefal devices is automatically configured. - 

40 it is also possible to construct a system using cbrrimph 1 appifcatibh prd'grams %nd to supply a common interface to 
all application programs irrespective of differences in personal computer hardware if the high-level OCX handling the 
interface to the application programs is capiable of absortiift^drffer^hces in specif ications caused by the personal com- 
puter hardware. The control system is created by the application program with common objects in the personal compu- 
ter, and a System appropriate to the personal <x>mputer ; and "peripheral devices connected thereto is automatically 

45 created by the custom controls OCX constituting the control system. : ! - * 

The control system using the custom controls OCX of thepreseht invention is thus an open system, and if the inter- 
face specifications are uniform and predetermined, application developers can develop and supply individual applica- 
tion programs without considering" the specifications of the personal computer arid peripheral devices connected 
thereto and without considering the method of connecting peripheral devices to the personal computer. Applications 

so can therefore be developed in a short time and supplied at a low 'cost. This architecture also makes it possible for indi- 
vidual users to freely select the applications suited to their own objectives and environment irrespective of the personal 
computer or peripheral devices used. *' 

Peripheral device suppliers can also supply general-puipo'se peripheral devices unrestricted to specific personal 
computer platforms or applications by providing with each device a low-level common object corresponding to the spec- 

55 if ications of the supplied peripheral device. This also enables iise?rs to freely purchase peripheral devices suited to their 
own objectives and environment and easily construct a* system designed for individual objectives. 

It should be noted that there are many different' types and numbers of peripheral devices that can be used, and 
while a POS system is described above as an example of a system in which various different types of peripheral devices 
are used according to individual user' environments, the present invention is not limited to POS systems. Systems built 
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around personal computers increasingly combine peripheral devices of various manufacturers and specifications 
according to the objectives and capabilities of the user. Control systems using common control objects according to the 
present invention are systems that can be flexibly adapted to a variety of user intentions, and can be applied to a variety 
of systems other than POS systems. 

5 

Embodiment 2 

Fig. 7 is a block diagram of the basic configuration of a control system according to the second embodiment of the 
present invention. In this embodiment IDispatch 13 is provided in a common object as the interface for receiving events. 
10 When events are communicated between custom controls OCX, the interface of the custom control OCX posting the 
event advises IConnectionPoint 12 about the event and IDispatch 13 receives the event for the OCX processing the 
event, i.e., the OCX posting the event passes an address identifier and opens a connection. Different identifiers can 
obviously be used under environments other than MFC, and different identifiers can be passed to either interface 12 or 
13. 

is In addition to providing an event interface 1 3 in a custom control OCX to enable two-way communications between 

custom controls OCX, an interface object 16 connecting event interfaces is also derived from the COIeDispatchDriver 
class in this embodiment. In other words, the control system of the present embodiment connects first OCX 1 0 and sec- 
ond OCX 1 1 by means of interface object 16 where first OCX 10 comprises IConnectionPoint 12 as the interface for 
posting events as described above and event IDispatch 13 as the interface for receiving events, and second OCX 11 
20 downstream from first OCX 1 0 comprises IConnectionPoint 12 as the interface for posting events. , 

In addition to a function for supplying the properties and events of second OCX 1 1 to first OCX 10, interface object 
16 of the present embodiment has a function for passing the address of event IDispatch 13 of first OCX 10 to IConnec- 
tionPoint 1 2 of second OCX 1 1 . When first OCX 10 generates interface object 1 6 of the present embodiment, and inter- 
face object 16 generates second OCX 11 according to first OCX 10, a connection between IConnectionPoint 12 of 
25 second OCX 11 and event IDispatch 13 of first OCX 10 is opened and events posted by. second OCX 11 can be 
received by first OCX 1 0. Two-way communication between second OCX 1 1 and first OCX 1 0 is therefore possible and 
there is no need for container application 20 to recognize second OCX 1 1 . Second OCX 1 1 can also be supplied as an 
object unaffected by the container application 20. 

Note that interface object 16 is derived from the COcxDispatchDriver class in the present embodiment. This 
30 COcxDispatchDriver class is an object class derived with multiple inheritance from the CCmdTarget class and the 
COIeDispatchDriver class, and is described as follows. 

class COcxDispatchDriver: public CCmdTarget, public COIeDispatchDriver {...}; 
As described above, the CCmdTarget class is the class for deriving objects with a server function, and the COIeDis- 
patchDriver class is an object class that operates as either client or controller for the second OCX 11, arid comprises a 
35 function for easily accessing methods and properties. 

The COcxDispatchDriver class is an object class comprising the two miain functions described above while inherit- 
ing and supporting all of the functions of both parent classes. The COcxDispatchDriver class is appropriate as an object 
class generating an interface object according to the present embodiment. Because there is no overlap between the 
operation and function of the CCmdTarget class and the COIeDispatchDriver class, there is also no problem created by 
40 multiple inheritance. 

The specification for the COcxDispatchDriver class is. as follows: 
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Class CO.cxDispatchDri.ver: public CCrndTarget, public COIeDispatchDriver { 
COcxDispatchDriver::COcxDispatchDriver(); // create 
public: // member data 

IID mJIDEvents; // event interface ID 
UINT mnEvents; // number of events 
: CDWordArray mdispID; .// array .for converting dispatch ID using user-defined dispatch 
map * . > 

public: " // member functions - • ■ 

BOOL PrecreateDisp.atch(REFCL§ID clsid,' \ 
CStringArray& EntryNames, 
CDWordArray& DisplDs, 
' CstrinQArray& Paramlhfo, .* . 

- * COJe Except ion * pJError == NULL) ; //creates an object; and stores interface information. 
BOOL EstablishGonnection(LPUNKNOWN pUnkSink, 
LPCDMENTRY' pDispMap,* 

CStringArray& EntryNames, : ' 

CDWordArray& QisplDs, • 

CStringArray& Paramlnfo, . ; .* ■ it ; , . * - 

COleException ^pError = NULL); // confirms event interface is same on posting^and 
receiving "sides, connects the two side^v- 
void DestroyConnectionO; // releases the connection, and deletes the object. 



The interface object derived from the COcxDispatch Driver class in thisembodiment has a function only for opening 
35 an event interface connection between custom controls OCX and, therefore, does not have an event processing func- 
tion (event handler). The..event handler is. provided in the custom pbntroi 1 OCX receiving the events. This is accom- 
plished as follows., , t( t V. 

A dispatch map is first described according to the : external name of the everrt(s) returned by the OCX posting the 
events. The sequence of events in the dispatch .map itiay ^W freely ordered ind the correlation to the sequence of 
40 events actually received is established when the event cdnnedtiori is established. Note that it is necessary to fully 
describe all OCX events. ( , 

Dispatch map entries may be described using a macro call siitfi aS follows with the major parameters being, in 
sequence, the dispatch driver class name, external event name, event handler name, return values, and parameter 
data. 

45 DISP_FUNCTION(__DSoprn, "Control CompleteEvenr, ControlCompleteEvent, VT_EMPTY, VTS_14 

VTS_SCODE VTS_PBSTR VTS_I4) 

The process for setting the connection between first OCX 1 0 and second OCX 1 1 by means of interface object 16 
derived from the COcxDispatchDriver class is described below with reference to the flow charts in Fig. 2 and Fig. 3. 
When interface object 16 is created and PrecreateDispatch is called, a second object OCX 11 defined by clsid is 
so created and begins executing as shown in step 31 of Fig. 2. Subsequent operation is the same as in the first embodi- 
ment above and further description is omitted. 

The process defining the correlation between the dispatch map and events is described next using the flow chart 
shown in Fig. 3. 

This process is started by setting in pUnkSink the identifier (the address of the event IDispatch of first OCX 10 in 
55 this embodiment) of the interface to first OCX 10, which is the object receiving events, and calling EstablishConnec- 
tionO- The counter fcnt is then cleared to zero in step 41 . The counter fcrrt is then read in step 42. Step 43 checks 
whether the event name Entry Names(fcnt) obtained from second OCX 1 1 is in the dispatch map pDispMap previously 
defined in the event handler of first OCX 10. rf the event name Entry Names(fcnt) is in the dispatch map pDispMap, it is 
then confirmed in step 44 whether the parameter data Paramlnfo(fcnt) matches the dispatch map pDispMap previously 
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defined in the event handler. 

If step 44 returns YES, step 45 then defines array m_displD for converting the dispatch ID DispIDs(fcnt) of the event 
obtained from second OCX 1 1 to an index in the dispatch map pDispMap previously defined in the event handler. The 
counter lent is then incremented in step 46, and the loop from step 42 to step 46 is repeated for each remaining event, 

s When the correlation to the dispatch map pDispMap is established, step 47 opens a connection for passing to the 

event handler of second OCX 1 1 the identifier, stored in pUnkSink, of the interface to first OCX 1 0. Because the present 
embodiment is described within the MFC environment, the address is passed to IConnectionPoint to establish the event 
connection. This makes it possible to pass events to first OCX 1 0 by calling the Invoke function of the second OCX 1 1 . 
More specifically, it is possible for first OCX 10 to receive events passed from second OCX 11. 

10 Step 48 checks whether the connection is successfully established. If so, the array m_disp)D for converting the 
event dispatch ID is stored in step 49. tf the preceding steps are all completed normaliy and the connection between 
interface object 1 6 and second OCX 1 1 is set, it is possible from step 50 to pass the methods and properties of second 
OCX 1 1 to first OCX 1 0, and to pass events from second OCX 1 1 to first OCX 10 

Fig. 4 is a flow chart of the process executed when the call lnvoke() posting events of the IDispatch interface of 

15 interface object 16 is called from second OCX 11. 

When lnvoke() is called, the structure storing the event parameters and the dispatch ID defining the current event 
type are passed to first OCX 10. The event-receiving first OCX 10 then checks in step 60 whether the parameters are 
valid. If the parameters are valid, step 61 converts the displDMembW array of events obtained from second OCX 1 1 
according to the prepared event handler dispatch map pDispMap based on the conversion array m_displD. The event 

20 handler corresponding to displDMember is then extracted from pDispMap in step 62. 

Step 63 confirms whether the event handler is valid or not. If the event handler is valid, the event handler corre- 
sponding to the event is called in step 64 and the process defined by the event handler, e.g., a process informing the 
application program of the event, is executed. K 

Although the present embodiment has been described with only one second OCX 11 linked to first OCX 10, multi- 

25 pie second OCX 1 1 can be connected to first OCX 1 0. If there is only one event-receiving interface, the event array must 
contain identical events and all second OCXs 1 1 should preferably be the same type. 

Application in a peripheral device control system 

30 An example of a peripheral device control system applying the control system of the second embodiment is shown 
in Fig. 8. In the control system of this example, the custom controls OCX on at least the first and second levels are 
objects comprising an IDispatch interface as described above for communicating events. Therefore, by connecting high 
and low level objects using interface objects 83a, 83b, and 84a - #4d according to the priesent invention, high and low 
level objects can be linked using an interface capable of communicating events in addition to methods and properties. 

35 Further description of this application is omitted because the configuration and operation thereof are the same as in the 
peripheral device control system shown in Fig. 6 and described abqve. 

Claims j 

40 1 . A control system that is used, in computers, .said ; control system comprising : 

a first control object (10) aqd one or more second control objects (1 1 ; 11a, 1 lb),, each of said first and second 
control objects having a respective first function for accessing one or more properties arid for invoking methods 
calling functions implemented therein, and having a respective second function for posting events including 
45 asynchronously occurring actions,.and 

one or more interface objects (15; 15a, 15b) each having a respective third function for communicating proper- 
ties and/or methods between said first control object, (10) and a respective second control object (11; 11a, 
1 1b), and having a respective fourth function for posting events from said respective second control object to 
said first control object. 

2. A control system according to Claim 1 wherein said first control object (10) is associated with a plurality of said sec- 
ond control objects (1 1a, 1 1 b), and a respective interface object (15a, 15b) is uniquely associated with a respective 
second control object (11a, 11b), each interface object (15a, 15b) comprising an independent identification means 
that can be referenced by said first control object (10). 

3. A control system according to Claim ,1 or 2 wherein a" respective second control object (1 1 ; 1 1a, 1 1b) posts plural 
events according to a first array and a respective interface object ( 1 5; /l 5a, 1 5b) comprises conversion means for 
converting said plural events to a.second array. ... 
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4. A control system according to Claim 3 wherein each interface object (15; 15a, 15b) is associated with a respective 
second control object (1 1 ; 1 1 a, 1 1 b) and each interface object comprises plural event processing means invoked 
according to said second array. ! 

5. A rnethocl for providing a control system according to any one of Claims 1 through 4. comprising the steps of: 

said.fiVst control object (10) creating said one or more second control objects (1 1 ; 1 1a, 1 1b). and 
. "said fir^t control pbject (1 0) creating for each of said second control objects (1 1 ; 1 1 a, 1 1 b) a respective inter- 
face object (15; 15a, 15b). / ' 

6. A method according to Claim 5 further comprising the steps of: 



said first control (1of object accessing an independent identification means for each interface object (15; 15a, 

15b), and. . , r 

75 * said second c6nW object (11; 11 a, i 1 b) posting said identification means with said events fd said first control 

object (10). . 

7. A method according to\&'aim 5 further ramprising" the steps of: ... 

20 creating a third array when'a respective interface object ( 1 5; 1 5a, 1 5b) is created, 

posting a plurality of events in a respective second control object (1*1 ; 1 1a, 1 lb) according to a first array, 
invoking, in response to each of said plurality of events, a corresponding one of a plurality of event processing 
means in said respective interface object (15; 15a, 15b) according to a second array, and' 
converting said f irst array Jo said second array according to contents of said third array. 



25 



8. A control system that is used in computers, comprising: 



a plurality of control objects (10, 11) each having a respective first function for accessing one or more proper- 
ties and for invoking methods calling functions implemented therein, and a f irst interface (12) for posting events 
30 including asynchronously occurring actions, a second one (1 1} of said control objects being created and con- 

trolled by a first one (1 0) of said cbntroj Objects, whetein \ . 

said first control object (10) comprises a secpnd interface (T3) for receiving events, and 
said control system further comprises 
35 a function for communicating properties anti/qr methods between said first cpntrol object (10) and said 

second control object (1 1), and' * \ t ; ^ '['I 

a function for passing an identifier of said second Interface (13) of the first control object (tO) to the first 
interface (12) of the second control object (11) or for passing an identifier of the first interface (12) of the 
second control object (1 1) to the second interface (13) of the first control object (10). 



40 



9. A control system according to Claim 8 wherein the second Control object (11 ) posts plural events according to a first 

array, and ; _ - , - - Ul . h , . . .. . . . „ ■ : 

the firet control object |l 0) corr^ 
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ohd array. 



10. A method of providing a control system according to claim 8 or 9 comprising the'steps of: 



said first control object (10) creating said interface object (16), 
said interface object ('1 6) Creating said second control objeit (1 1 ), and 
so establishing a connection between the second interface (1 3) of the first control object (10) and the first interface 

(12) of the second control object (11). 

11. A method according to Claim 10 for providing a control system according to claim 9, wherein said step for estab- 
lishing a connection further creates a third array for' c»nveftfngtfie second array to the first array. 
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12. A peripheral device control system (70) for controlling peripheral devices (1 12, 1 13, 1 15) of an application system 
by means of a control system according to any one of claims; 1 to 4, 8 or 9. wherein each of a plurality of control 
object groups includes a first controf object (75-78), a second 'control object (91-94)) and an interface object (82a- 
82d; 84a-84d), and wherein each second control object (91-94) is associated with' a corresponding one of said 
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peripheral devices (112, 113, 115). 

13. A system (70) according to Claim 12 wherein the properties of a respective second control object (91-94) includes 
attribute values corresponding to unique specifications of the associated peripheral device (1 12, 1 13, 115), 
5 the methods of the respective second control object (91-94) include commands specific to the associated 

peripheral device (112, 113, 115), and 

the events of the second control object (19-94) correspond to actions occurring asynchronously in the asso- 
ciated peripheral device (1 12, 1 13, 1 15). 

to 14. A control system (70) according to Claim 12 or 13 wherein the first control object (75-78) converts the properties, 
methods and/or events of the second control object (91-94) communicated through said interface object (82a-82d; 
84a-84d) to a universal specification. - 
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15. A system (70) according to Claim 12, 13 or 14 wherein the application system is a point-of-sale control system. 
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